Method and system for selecting a data compression technique for data transfer through a data network

ABSTRACT

A method and system for selecting a data compression technique for data transfer through a data network is provided. During call setup, information is gathered from the network infrastructure by receiving feedback from smart network devices, reviewing calls logs, or by accessing a network topology database, and the information can then be used to select a desired compression technique. During a call, a media terminating end device or a call control server will monitor call connection performance specific to the data transfer pathway used for the call connection, and may adjust the data compression to conform with the performance that the connection is providing at any given moment. Performance parameters such as delay, jitter, and compression ratios can be measured in real-time for a call to determine if a change in compression is deemed beneficial. In this manner, the compression method can be chosen based on real time network performance.

FIELD OF INVENTION

The present invention relates to data transfer through IP data networks,and more particularly, to a method and system for selecting a datacompression technique for data transfer through a data network.

BACKGROUND

Internet protocol (“IP”) telephony and IP multimedia networks are widelyused to setup and manage calls and sessions. To do so, a codec, whichrefers to a coder-decoder or a compression-decompression device, isgenerally used to convert an audio signal into a compressed digital formfor transmission through the network to reduce file sizes and back intoan uncompressed audio signal for play out at a media terminating device.Media terminating devices in IP Telephony (e.g., phones and gateways)support multiple types of codecs.

Codecs range from non-compressed (no loss of information) to compressed(loss of information but good quality under certain conditions). Whilenon-compressed codecs have higher quality, they use more bandwidthcompared to non-compressed codecs. In general, it is desirable to createa system that uses non-compressed codecs where bandwidth is cheap andabundant (e.g., within local area networks (LAN)) and use compressedcodecs where bandwidth is costly and scarce (e.g., within wide areanetworks (WAN)).

Since many media terminating devices support multiple codecs, aselection technique is necessary. IP networks are usually configured togive certain codecs preference over others. For example, mediaterminating devices are set to have starting preferences, and uponconnection, the devices use the highest priority codec that bothcommunicating devices can support. However, using default preferencesfor all types of connections does not always provide a desirableconnection. For example, if high compression codecs are set for toppriority, then a majority of calls would suffer a loss of informationeven when it is unnecessary. Further, using default preferences forcalls may not allow codec negotiation during a call, such as by takinginto consideration network delays, time of day, or other networkcharacteristics.

Thus, it is desirable to provide a codec selection technique that mayprovide an optimal data compression for each specific connection.

SUMMARY

In an example of an embodiment, a method for selecting a datacompression technique for data transfer through a network between afirst network device and a second network device is provided. The methodincludes receiving information of a configuration of the network betweenthe first network device and the second network device. The informationincludes data transfer speeds through the network. The method furtherincludes selecting a data compression technique for data transferthrough the network between the first network device and the secondnetwork device based on the information. The method may be performed bya call control server residing in the network, or by the first or secondnetwork device, and the method can be performed during call setup orduring a call between the first and second network device.

In one example, the first network device will determine theconfiguration of the network between the first network device and thesecond network device by identifying a data transfer path between thefirst network device and the second network device, and then identifyingintermediary links in the data transfer path between the first networkdevice and the second network device. The first network device can thendetermine data transfer capabilities of the intermediary links in thedata transfer path between the first network device and the secondnetwork device to select the data compression technique for datatransfer through the network to the second network device.

Many different types of information regarding the configuration of thenetwork between the first network device and the second network devicecan be obtained to be used to select a data compression technique fordata transfer between the first and second network devices. For example,the information may include a network topology between the first networkdevice and the second network, information regarding intermediary linkscontained within a data path between the first network device and thesecond network device, information regarding where the first networkdevice and the second network device are located within the network,call history information for prior calls between the first networkdevice and the second network device, information from a smart networkdevice including whether uncompressed data is being transferred over aslow speed link or whether compressed data is being transferred over ahigh speed link, performance parameters such as a packet delivery delaytime in the network, a jitter time in the network, and a packet lossfactor of the network, and information regarding a time of day.

In another example of an embodiment, a method for selecting a datacompression technique for data transfer through a network between afirst network device and a second network device is provided. The methodincludes transferring data in a compressed format between the firstnetwork device and the second network device through intermediary linksin the network. The method also includes determining a quality of datatransfer through the intermediary links in the network, and thenadjusting the compressed format based on the quality of data transfer.

These as well as other features, advantages and alternatives will becomeapparent to those of ordinary skill in the art by reading the followingdetailed description, with appropriate reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF FIGURES

FIG. 1 is a block diagram of one embodiment of a network telephonysystem.

FIG. 2 is a block diagram of one embodiment of a media terminatingdevice.

FIG. 3 is a block diagram of one embodiment of a call control server.

FIG. 4 is a flowchart depicting one embodiment of a method for selectinga data compression technique for data transfer through a network.

FIG. 5 is a message flow diagram illustrating one embodiment ofselecting a data compression technique during call setup.

FIG. 6 illustrates one example of a system including media terminatingdevices located on the same access network.

FIG. 7 is a flowchart depicting another embodiment of a method forselecting a data compression technique for data transfer through anetwork.

FIG. 8 illustrates one embodiment of signaling to adjust a datacompression technique for data transfer between network devices.

FIG. 9 is a block diagram illustrating one embodiment of a systemincluding smart network device feedback.

DETAILED DESCRIPTION OF EMBODIMENTS

In one embodiment, a method of selecting a data compression technique inan IP telephony network is provided. The method may be performed duringcall setup or during the call. During call setup, information can begathered from the network infrastructure by (i) accessing networktopology information from a network management database, (ii) receivingfeedback from smart network devices that report if they recognizeuncompressed data being transferred over a slow speed link or compresseddata being transferred between two network phones known to be connectedby a high speed connection, or (iii) reviewing calls logs to identifyactual performance between phones, for example. The information can thenbe used to select a desired compression technique to be used for datatransfer through the network.

During a call, a media terminating end device, e.g., network telephone,or a call control server will monitor call connection performance andmay adjust the data compression to conform with the performance that theconnection is providing at any given moment. For example, performanceparameters such as delay, jitter, and compression ratios can be measuredin real time for a call to determine if a change in compression isdeemed beneficial. If so, the phone may send a request to a device onthe other end of the connection to request a change in the compression.In this manner, the compression method is chosen based on real timenetwork performance.

Referring now to the figures, and more particularly to FIG. 1, a blockdiagram of one embodiment of a network telephony system 100 isillustrated. It should be understood that the system 100 illustrated inFIG. 1 and other arrangements described herein are set forth forpurposes of example only, and other arrangements and elements can beused instead and some elements may be omitted altogether, depending, forexample, on manufacturing and/or consumer preferences.

The system 100 includes media terminating devices 102 and 104 coupled toa data network 110 through access networks 106 and 108. The mediaterminating devices 102 and 104 are shown to be IP network phones.However, the media terminating devices 102 and 104 may be any networkdevice such as personal computers with user interface hardware like amicrophone and headphone to communicate voice information, a personaldigital assistant (PDA) with voice communication capabilities, or othercommunication devices. In addition, more media terminating devices maybe included in the system 100.

The access networks 106 and 108 may be any type of networks that connectthe media terminating devices 102 and 104 to the data network 110. Forexample, the access networks 106 and 108 may be local area networks(LAN) whether wired or wireless, or others, and the link between themedia terminating devices 102 and 104 and the access networks 106 and108 may be wired or wireless as well. The data network 110 may be a LAN,a WAN, or generally a data packet network such as an Internet Protocol(IP) network. The data network 110 interconnects the access networks 106and 108 could also be a virtual private network (VPN) or the Internet, alease line of a corporate network, or a campus backbone network, forexample. The media terminating devices 102 and 104 may communicate witheach other or with other through the data network 110.

The data network 110 also couples to a call control server 112. The callcontrol server 112 establishes and monitors data transfer between themedia terminating devices 102 and 104. The call control server 112 willreceive call setup messages from the media terminating devices 102 and104 when the devices initiate a call. In addition, during a call betweenthe media terminating devices 102 and 104, the call control server 112may receive reporting messages from the devices that include datatransfer statistics for the call. Thus, the call control server 112observes operation of the media terminating devices 102 and 104 based onmessages received from the devices.

The call control server is connected to a database 114. The database 114stores general information concerning the system 100, and specificinformation concerning past performance of the system 100. For example,the database 114 may include a call log detailing specific data transferrates between network devices residing on the data network 110 for callsbetween the network devices. The database 114 may also includeinformation relating to bandwidth capabilities of the data network 104and/or bandwidth capabilities of network equipment within the datanetwork 110. The database 114 may further include a table of all networkdevices residing on the data network 110 that are registered with thedata network 110 and the network devices' associated IP addresses.

The system 100 may also include a network management topology database116 coupled to the call control server 112 and the data network 110. Thedatabase 116 includes information pertaining to a topology of the system100, such as data paths between network devices in the system 100. Forexample, the database 116 may contain a table that includes possibledata transfer paths between any two network devices residing in thesystem. The data transfer path information may include all intermediarylinks between two network devices. Alternatively, the database 116 mayinclude information pertaining to all the links within the system 100,and how the links are interconnected such that the call control server112 could determine data transfer pathways between network devices usingthis information. Thus, the call control server 112 or media terminatingdevices 102 and 104 may then access the database 116 to identify theintermediary data transfer links between the media terminating devices102 and 104.

The database 116 may include any third party network management toolthat includes network mapping capabilities, such as HP OpenView®available from the Hewlett-Packard Company or IBM Tivoli NetView. Themedia terminating devices 102 and 104 and the call control server 112can access the database 116 to identify a data transfer path between themedia terminating devices 102 and 104, determine the slowest link in thepath (e.g., possibly based on data transfer speeds and availablebandwidth of the link), and adjust data transfer accordingly.

FIGS. 2 and 3 are block diagrams that illustrate an exemplary mediaterminating device 102 and an exemplary call control server 112. Itshould be understood that these and other arrangements described hereinare set forth for purposes of example only, and other arrangements andelements can be used instead and some elements may be omittedaltogether. Further, many of the elements described herein arefunctional entities that may be implemented as hardware, firmware, orsoftware, and as discrete components or in conjunction with othercomponents, in any suitable combination and location.

As shown in FIG. 2, the media terminating device 102 includes aprocessor 202, a codec 204, a user interface 206, a network interface208, and memory 210. The memory 210 includes a number of applicationsexecutable by the processor 202. The applications may be in the form ofexecutable instructions accessible by the processor 204 to performspecific tasks. In addition, some of the applications can be implementedfully or in part through application logic hardware. The applicationsinclude a quality of connection application 212 executable to determineperformance statistics related to a call connection, a data compressionapplication 214 executable to select a desired data compressiontechnique, a reporting application 216 executable to send messages tothe call control server 112 including information relating to statisticsof a call connection, a call setup application 218 executable toinitiate a call with another network device, and other deviceapplications 220 such as conference call functions, phone number storageand retrieval, etc. The media terminating device 102 may include otherapplications as well.

As shown in FIG. 3, the call control server 112 includes a processor302, a database 304, a network interface 306, and memory 308. The memoryincludes a number of applications executable by the processor 302. Theapplications may be in the form of executable instructions accessible bythe processor 302 to perform specific tasks. The applications include adata compression selection application 310 executable to select a datacompression technique, a request reporting messages application 312executable to request messages from the media terminating devices 102and 104, a receive reporting messages application 314 executable toreceive messages from the media terminating devices 102 and 104, aquality report application 316 executable to generate a quality reportof data transfer between network devices, a query database application318 executable to query the network management database 116, and otherdevice applications 320 such as network management applications, voicemail, hold music, etc. The call control server 112 may include otherapplications as well.

To conserve bandwidth in the system 100, media terminating devices cantransfer data in a compressed format. To compress multimedia data, acodec is generally used to convert an audio signal into a compresseddigital form for transmission through the network to reduce file sizesand back into an uncompressed audio signal for play out at a mediaterminating device.

Data may be compressed using any standard compression algorithm ortechnique. Some examples include G.711, G.726 or G.729. G.711 isdescribed in “Pulse Code Modulation of Voice Frequencies,” ITU-TRecommendation G.711, G.726 is described in “40, 32, 24, 16 kbit/sAdaptive Differential Pulse Code Modulation (ADPCM),” ITU-TRecommendation G.726, and G.729 is described in “Coding of Speech at 8kbit/s using Conjugate-Structure Algebraic-Code-ExcitedLinear-Prediction (CS-ACELP),” ITU-T Recommendation G.729. ITU-TRecommendations G.711, G.726 and G.729 are each incorporated byreference herein as if fully set forth in this description. These areexamples only, since many other compression techniques exist as well.Further, higher bandwidth audio requirements may arise for certain typesof data packets, and in such cases, other specialized data compressiontechniques can be developed.

G.711 data compression can be used for low compression techniques or ininstances where bandwidth is plentiful. For example, telephone companiestransmit voice at minimal compression levels such as at 64 kbit/s usingG.711 for high quality data transmission due to the availability of highbandwidth data transfer links. G.729 data compression can be used forheavy compression techniques or in instances where bandwidth is scarce.For example, using G.729, data is compressed and transferred at 8kbit/s, which is an 8:1 data compression, and the quality of datatransmission is less than G.711 due to loss of data. As another example,G.726 data compression can be used to compress data to sizes in betweenthose offered by G.711 and G.729. G.726 is an intermediate datacompression technique that is used to compress data to 32 kbit/s, whichis a 2:1 data compression and results in a low loss in quality of thedata.

As such, many types of codecs may be used within network devicesdepending on the type of data being compressed and transferred. Thus,the media terminating devices 102 and 104 may support multiple types ofcodecs and multiple types of data compression techniques.

In one embodiment, the media terminating devices 102 and 104 or the callcontrol server 112 may select a data compression technique for datatransfer between network devices residing in the system 100 based on thetopology of the system 100. FIG. 4 is a flowchart depicting oneembodiment of a method for selecting the data compression technique.Initially, the media terminating devices 102 and 104 or the call controlserver 112 will receive information of a configuration of the networkbetween the media terminating devices 102 and 104, as shown at block402. For example, information concerning links that transfer databetween the devices 102 and 104, such as the types and number of accessnetworks used, can be requested from the network management topologydatabase 116. The database 116 can then send such information to thecall control server 112 directly, or to the media terminating devices102 and 104 through the data network 110.

Next, the media terminating devices 102 and 104 or the call controlserver 112 will determine characteristics of the intermediary links inthe network from the information received, as shown at block 404.Intermediary links of interest may be those contained within a data pathbetween the media terminating devices 102 and 104. For example, datarates and available bandwidth of access networks can be identified basedon the types of access networks used. Other characteristics can beidentified as well, such as packet loss and packet delay resulting fromdata packet transfer through the intermediary links.

Following, the media terminating devices 102 and 104 or the call controlserver 112 will select a data compression technique for data transferbetween the media terminating devices 102 and 104 based on thecharacteristics of the links, as shown at block 406. For example, thedata compression technique may be selected based on total availablebandwidth, an instantaneous available bandwidth, or administrationcontrol of bandwidth. Thus, as an example, if a slowest link along adata transfer path has the ability to transfer data at 64 kbit/s, then ahigh compression technique can be used, such as the G.729 compressiontechnique (e.g., 8 kbit/s), such that the bandwidth on the slowest linkwill not be exhausted for one phone call.

As another example, if the slowest link in a data transfer path is a T1link (e.g., 1.5 mbit/s) into a data network, then the G.711 datacompression may be chosen since there is ample bandwidth available. A T1data link can be used to transfer data between devices residing on aWAN. However, in such a case, administrative controls may be set tofurther conserve bandwidth and to dedicate this link as a compressedlink. In this case, a data compression technique is selected based onavailable bandwidth and the administrative settings.

The method described in FIG. 4 for data compression technique selectionmay be performed during a call setup between network devices, or duringa call between network devices. A call or data connection between twonetwork devices can be established using any IP based call signaling.

In one example embodiment, a call is setup and performed using theSession Initiation Protocol (SIP) signaling protocol. SIP is describedin Handley, et al., “SIP: Session Initiation Protocol,” IETF (RFC) 2543,March 1999, which is entirely incorporated by reference herein, as iffully set forth in this description. The SIP is also described inRosenberg et al., “SIP: Session Initiation Protocol,” IETF (RFC) 3261,June 2002, the contents of which are entirely incorporated herein byreference, as if fully set forth in this description. Other signalingprotocols, such as H-323, MGCP, MEGACO, and other standard orproprietary techniques may alternatively be used.

The SIP protocol is a text-based protocol in which one party sends amessage in American standard code for information interchange (ASCII)text consisting of a method name on the first line, followed byadditional lines containing headers for passing parameters. Many of theheaders are taken from multipurpose Internet mail extensions (MIME) toallow SIP to interwork with existing Internet applications.

As an example, consider the following exemplary text encoded message.

INVITE sip:user@biloxi.com SIP/2.0 Via: SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: User<sip:user@biloxi.com> From: Sender<sip:sender@atlanta.com>;tag=1928301774 Call-ID:a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact:<sip:sender@pc33.atlanta.com> Content-Type: application/sdpContent-Length: 142

The first line of this text-encoded message contains the method name(e.g., INVITE). The lines that follow are a list of header fields. Forexample, the fields Via (describing the address at which the user isexpecting to receive responses), To (contains a display name or SIPrequest-URI towards which the request was originally directed), From(contains a display name and a SIP request-URI that indicate theoriginator of the request), Call-ID (contains a globally uniqueidentifier for this call), CSeq (a traditional sequence number), andContact (contains a SIP request-URI that represents a direct route tocontact the sender) are header fields. In addition, the From header alsohas a tag parameter containing a random string (e.g., 1928301774) thatused for identification purposes.

Other example methods are provided below in Table 1.

TABLE 1 METHOD DESCRIPTION INVITE Request initiation of a session ACKConfirm that a session has been initiated BYE Request termination of asession OPTIONS Query a host about its capabilities CANCEL Cancel apending request REGISTER Inform a redirection server about the user'scurrent location

Using the methods in Table 1, many types of SIP call flows can beperformed, such as those described in RFC 3665, entitled “SessionInitiation Protocol (SIP) Basic Call Flow Examples,” which is entirelyincorporated by reference as if fully set forth in this description. Asone example, to initiate a call, the media terminating device 102 (“thecaller”) sends an INVITE message to the media terminating device 104(“the callee”) by way of the access network 108. The transport protocolfor the transmission may be transmission control protocol (TCP) or userdatagram protocol (UDP), for example. In both cases, the headers on thesecond and subsequent lines of INVITE message describe the structure ofthe message body, which contains the caller's capabilities, media types,and formats. The INVITE message also contains a user identifier toidentify the callee, a caller user identifier to identify the caller,and a session description that informs the called party what type ofmedia the caller can accept and where the caller wishes the media datato be sent. User identifiers in SIP requests are known as SIP addresses.SIP addresses are referred to as SIP Universal Resource Indicators (SIPrequest-URIs), which are of the form sip: user@host.domain. Otheraddressing conventions may also be used.

The access network 108 locates the callee and transmits an INVITErequest to the callee. The INVITE request may simply be a forwardedversion of the INVITE request, containing the SIP addresses of thecaller and the callee. Upon receiving the INVITE request, the callee maytransmit a response message to the access network 108. The accessnetwork 108 may then transmit a response message back to the caller. Theresponse messages may be reply codes. A reply code may be a three-digitnumber with a classification as defined below in Table 2.

TABLE 2 CODE MEANING EXAMPLES 1xx Information 100 = server agrees tohandle client's request 2xx Success 200 = request succeeded 3xxRedirection 301 = page moved 4xx Client Error 403 = forbidden page 5xxServer Error 500 = internal server error

For example, if the callee accepts the call, the callee responds with a200 OK message. Following the reply code line, the callee also maysupply information about the callee's capabilities, media types, andformats.

If the transmitted response message is a success response (i.e.,represented by a SIP “200 OK” response), then the caller may send an ACKmessage back to the callee to confirm receipt of the 200 OK message andcomplete the call initiation process. The ACK message may be sentthrough the same path as the INVITE request and response messages. Afterthe call has been initiated using the SIP signaling protocol, the callis connected and media data (including voice information, etc.) can flowon a data channel between the media terminating devices 102 and 104.

Selecting Data Compression Technique During Call Setup

In one embodiment, the media terminating devices 102 and 104 or the callcontrol server 112 will select a data compression technique for datatransfer during call setup. A call or data connection between twonetwork devices can be carried out using any standard IP telephonyprotocol, such as Session Initiation Protocol (SIP), the H.323 protocol,the Media Gateway Control Protocol (MGCP), the Media Gateway ControlProtocol (MEGACO), and other standard or proprietary protocols mayalternatively be used. In an example embodiment, the call connection isperformed using the SIP signaling protocol. During call setup, thenetwork management topology database 116 can be accessed by the mediaterminating devices 102 and 104 through the data network 110, ordirectly by the call control server 112, to receive information aboutthe system's infrastructure. Subsequently, a data compression techniquecan be chosen according to the network topology between a source anddestination media network device.

As one example, FIG. 5 is a message flow diagram illustrating oneembodiment of signaling to select a data compression technique duringcall setup. Initially, a network device, such as media terminatingdevice 102, will send a message to the call control server 112 torequest to place a call, as shown at message 502. The media terminatingdevice 102 may request to place a call to media terminating device 104,for example. The message may be a SIP INVITE message that is used toinitiate a real time protocol (RTP) media session as described above.

The call control server 112 will then identify IP addresses of the mediaterminating devices 102 and 104, as shown at message 504, to initiatethe call. The call control server 112 will identify the IP addresses byquerying the database 114, for example, and the database will return theIP addresses, as shown at message 506. (Alternatively, the call controlserver 112 may identify the IP addresses from information includedwithin the SIP INVITE message). Next, the call control server 112 willrequest data path information from the network management topologydatabase 116, as shown at message 508. For example, the call controlserver 112 will request the network management topology database 116 toidentify where the media terminating devices 102 and 104 are located andany intermediary links that are contained within a data transfer pathbetween the media terminating devices 102 and 104. In response, thenetwork management topology database 116 will identify the data pathinformation using the IP addresses of the media terminating devices 102and 104 using any standard network mapping algorithm, and return thedata path information to the call control server 112, as shown atmessage 510.

The call control server 112 will use the data path information todetermine a data compression technique that the media terminatingdevices 102 and 104 will use for the call. Thus, the call control server112 will return the data compression technique to the media terminatingdevice 102, as shown at message 512. The call control server 112 mayalso send a message indicating the data compression technique to themedia terminating device 104. The call between the media terminatingdevices 102 and 104 may then begin and data will be transferred betweenthe devices in the selected compressed format.

Many methods exist for selecting the data compression technique based onnetwork topology information. Some examples are listed below. However,it should be understood that these are exemplary only, since many othertechniques for selecting a data compression technique based on networktopology information exist.

Identifying Intermediary Links

In one embodiment, the call control server 112 or the media terminatingdevices 102 and 104 will determine the data compression technique byidentifying any intermediary links within the data transfer path anddetermining maximum data transfer speeds through these links. The callcontrol server 112 or the media terminating devices 102 and 104 mayidentify any intermediary links within the data transfer path byaccessing the network management topology database 116 using the simplenetwork management protocol (SNMP). The call control server 112 or themedia terminating devices 102 and 104 could read the network topologyinformation, and using this information find where media terminatingdevices are located in the network topology, and then traverse thenetwork topology from one media terminating device to the other, notingeach link between the devices and each link's capabilities. For example,the media terminating device 102 could access the database 116 throughaccess network 106 and data network 110 and retrieve informationcorresponding to the network topology present between itself and themedia terminating device 104. The media terminating device 102 couldthen determine that access networks 106 and 108 and data network 110comprise the links between media terminating devices 102 and 104.

In addition, the call control server 112 or the media terminatingdevices 102 and 104 may identify any intermediary links within the datatransfer path by sending the network management topology database 116the two IP addresses of the communicating devices (e.g., as obtainedfrom the SIP INVITE call setup messages) and the network managementtopology database 116 would return a description of the data pathbetween the two IP addresses. The returned information may containintermediary link capabilities in the data path description, or the callcontrol server 112 or media terminating devices may need to do furtherinquiries to the network management topology database 116 about thecapabilities of each link in the data path description.

After analyzing all intermediary links, the call control server 112 orthe media terminating devices will identify the slowest transfer speedof any link within a data path, and select a data compression techniqueto be used based on the slowest link's limitations. For example, if anintermediary link is a LAN, the call control server 112 will estimatedata transfer speeds of 10, 100, 1000 or 10000 megabits per second andaccordingly select a data compression technique that can accommodate theavailable bandwidth.

As other examples, the G.729 data compression may be used for datatransfer when 64 kbit/s or less bandwidth is available, and no datacompression may be used when 10 mbit/s or more is available (e.g., asmay be available when transferring data through a LAN). Whentransferring data through links with available bandwidth ranging from 64kbit/s to 10 mbit/s (e.g., such as when using a T1 data link thatprovides 1.5 mbit/s), network administrators may choose to manage theavailable bandwidth by using the G.729 or G.726 data compression.Usually, network administrators will utilize some type of datacompression when bandwidth falls below 64 kbit/s.

Identifying Subnet Information

In another embodiment, the call control server 112 or the mediaterminating devices may determine the data compression speed bydetermining the subnet where the media terminating devices 102 and 104reside based on their IP addresses, and then determine a data transferspeed of that type of subnet. For example, if both the media terminatingdevices 102 and 104 are located on the same LAN, then a low datacompression technique could be selected. FIG. 6 illustrates one exampleof a system 600 including media terminating devices 104 and 120 locatedon the same access network 108. Thus, data transfer between the mediaterminating devices 104 and 120 does not need to traverse through thedata network 104. As a result, data transfer rates may be high, and alow compression technique may then be selected so that little or no lossof data results from the transfer of data from one media terminatingdevice to another.

The call control server 112 may determine where the media terminatingdevices 102 and 104 are located by accessing the database 114 andperforming a lookup using the IP addresses of the media terminatingdevices 102 and 104. The database 114 may contain such information basedon registration of the media terminating devices 102 and 104 with thedata network.

In addition, the media terminating devices 102 and 104 may determine ifthey reside on the same subnet during call setup. For example, duringcall setup, the media terminating devices 102 and 104 could exchange SIPINVITE messages through the access network 108 to establish a call. As aspecific example, if media terminating device 102 sent the SIP INVITEmessage shown below to media terminating device 104, then mediaterminating device 104 could determine that it resides on the samenetwork as media terminating device 102 because the header fields “To”(e.g., contains a display name or SIP request-URI towards which therequest was originally directed), and “From” (e.g., contains a displayname and a SIP request-URI that indicate the originator of the request)include SIP network addresses with the same domain.

INVITE sip:user@chicago.com SIP/2.0 Via: SIP/2.0/UDPpc33.chicago.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: User<sip:user@chicago.com> From: Sender<sip:sender@chicago.com>;tag=1928301774 Call-ID:a84b4c76e66710@pc33.chicago.com CSeq: 314159 INVITE Contact:<sip:sender@pc33.chicago.com> Content-Type: application/sdpContent-Length: 142In example above, the call is established without signaling through thecall control server 112. Thus, the media terminating devices 102 and 104can determine a data compression technique during call setup on theirown by identifying if they reside on the same subnet. If so, the devicescan transfer data uncompressed due to the availability of bandwidth.

Call History Information

In still another embodiment, information concerning prior calls throughthe system 100 is used to select a data compression technique. Forexample, information regarding calls through the system 100 can beperiodically gathered to build a call log or source/destination linktable. Such information may include data transfer rates of calls forspecific data pathways. The call log and source/destination link tablesmay be included within the database 114. Thus, when a network devicerequests initiation of a call, the call control server 112 (or thenetwork devices) could access the source/destination table in thedatabase 114 to determine an available data pathway for data transfer tothe network device to which he requests to call. In addition, the callcontrol server 112 could alternatively query a device, (e.g., a thirdparty network management application designed for voice environmentsthat gathers statistics about network performance and call quality),that provides the service of looking into call logs and responding to aquery concerning a source/destination subnet or address pair to providea data transfer rate of a preferred data pathway. Thus, the call controlserver 112 would be reviewing calls logs to identify past data transferrates between network devices.

An example call log table is shown below in Table 3.

TABLE 3 Network Network Network Device A Device B Device C NetworkPacket Loss: 2% Packet Loss: 2% Packet Loss: 1% Device D Packet Jitter:Packet Jitter: Packet Jitter: 50 ms 20 ms 10 ms Packet Delay: PacketDelay: Packet Delay: 100 ms 50 ms 10 ms Network Packet Loss: 3% PacketLoss: 2% Packet Loss: 2% Device E Packet Jitter: Packet Jitter: PacketJitter: 30 ms 50 ms 5 ms Packet Delay: Packet Delay: Packet Delay: 500ms 100 ms 10 ms Network Packet Loss: Packet Loss: Packet Loss: Device G0.5% 1.2% 1% Packet Jitter: Packet Jitter: Packet Jitter: 10 ms 15 ms 5ms Packet Delay: Packet Delay: Packet Delay: 10 ms 20 ms 10 ms

Table 3 indicates call statistics for previous calls between thespecified network devices. The call statistics include packet loss,packet jitter and packet delay. For example, for previous calls fromnetwork device D to network device A, the packet loss has been measuredto be 2%, the packet jitter has been measured to be 50 ms and the packetdelay has been measured to be 100 ms. These measurements may be theaverage measurement of such characteristics over a period of time, orthe measurements may correspond to statistics at a particular time ofthe day. The statistics can be compiled in other manners as well.

The statistics in the call log table can be used to select a datacompression technique during call setup that will be used for datatransfer between network devices. For example, if the packet loss ismore than a few percent, this may indicate that this data transferpathway is overloaded, and thus data transfer for a new call should becompressed. Further, if the packet jitter or the packet delay is as highas about 50-100 ms, then again the data transfer pathway may be heavilyloaded, and thus data should be compressed accordingly for calls betweenthese devices.

An example source/destination or data pathway table is shown below inTable 4.

TABLE 4 Network Network Device A Device B Network Device C NetworkBandwidth: 1.5 mbit/s Bandwidth: Bandwidth: Device D Time: 6:00 am 1.5mbit/s 10 mbit/s Bandwidth: 1.2 mbit/s Time: 6:00 am Time: 6:00 am Time:7:00am . . . . . . . . . Network Bandwidth: 64 kbit/s Bandwidth:Bandwidth: Device E Time: 6:00 am 1.5 mbit/s 64 kbit/s . Time: 6:00 amTime: 6:00 am . . . . . . . . Network Bandwidth: 10 mbit/s Bandwidth:Bandwidth: Device G Time: 6:00 am 64 kbit/s 64 kbit/s . Time: 6:00 amTime: 6:00 am . . . . . . . .

Table 4 illustrates limiting factors for data transfer between networkdevices. For instance, Table 4 includes available bandwidth within adata transfer pathway between network devices at specific times duringthe day. A data transfer pathway may include may network components oraccess networks. The information included in Table 4 corresponds to theslowest data transfer link between the two communicating networkdevices. As one example, the data transfer pathway between networkdevice A and D includes a slowest link with an available bandwidth of1.5 mbit/s at 6:00 am, but only 1.2 mbit/s at 7:00 am. Bandwidth willdecrease as more users attempt to transfer data. As a result, at peaktimes during a day, the available bandwidth will be at a minimum. Table4 may take other forms as well. That shown above is only one example.

The information in Table 4 can be used to select a data compressiontechnique. For example, at 6:00 am, the average bandwidth available fora data transfer pathway between network device A and network device D is1.5 mbit/s, and thus the G.711 compression technique could be selectedfor low data compression.

Other Characteristics

In other embodiments, the call control server 112 may select a datacompression technique based on other system characteristics as well (inaddition to or rather than previously described information). Forexample, the time of day can be taken into account when selecting a datacompression technique because usually system performance is slower orfaster at certain times of the day. Other characteristics may also beconsidered.

Selecting Data Compression Technique During a Call

In another example embodiment, the media terminating devices 102 and 104or the call control server 112 may select a data compression techniquefor data transfer during a call. For example, the call control server112 or the network devices can periodically (or on demand), adjust thedata compression rates being used in a call to better accommodate systemcapabilities during the call.

FIG. 7 is a flowchart depicting another embodiment of a method forselecting a data compression technique for data transfer through anetwork. Using the system 100 illustrated in FIG. 1 as an example,initially, the media terminating device 102 will be in a call sessionwith the media terminating device 104 and the two network devices willtransfer data between each other in a compressed format, as shown atblock 702.

The media terminating devices 102 and 104 will measure the quality ofthe call, as shown at block 704. Alternatively, the media terminatingdevices 102 and 104 can measure the quality of the call and send areporting message (e.g., a SIP INVITE message) including statisticsrelating to the call quality to the call control server 112. The callcontrol server 112 may then determine a quality of data transfer betweenthe media terminating devices 102 and 104 through the intermediary linksin the system 100.

The media terminating devices 102 and 104 may implement tools togenerate reports and to estimate a quality of calls. For example, theRTP control protocol (RTCP) can be used to provide feedback on thequality of data transmission. RTCP is described in Schulzrinne et al.,entitled “RTP: A Transport Protocol for Real-Time Applications,” IETF(RFC) 3550, July 2003, which is entirely incorporated by referenceherein, as if fully set forth in this description.

The media terminating devices 102 and 104 may provide quality reportsusing RTCP report packets that may be in many forms including a senderreport (SR) or a receiver report (RR). The SR is issued if a sendingdevice has sent any data packets during the interval since issuing thelast report or the previous one, otherwise the RR is issued. Both the SRand RR forms include zero or more reception report blocks, one for eachsynchronization source from which the receiving device has received RTPdata packets since the last report. Each reception report block providesstatistics about data received from a particular source indicated inthat block. The statistics may include timestamps of when data packetswere received, number of data packets received, number of data packetssent, inter-arrival jitter time, delay since last SR was sent, andothers. The media terminating devices can then measure a quality of acall by analyzing these statistics using sequence numbers and timestamps contained in the data packets.

After determining a quality of the call, the media terminating devices102 and 104 or the call control server 112 may adjust the datacompression rates based on the quality of the call, as shown at block706. The compression format can be adjusted without putting the call onhold. A user may not notice a difference during the data compressionadjustment except for an improved voice quality. Messaging used torequest a change in data compression depends on the call signalingprotocol used. In the case of the SIP, a call setup message (e.g.,INVITE message) can be sent to adjust the data compression technique.

FIG. 8 illustrates one embodiment of signaling to adjust the datacompression technique. FIG. 8 illustrates call setup followed byadjustment of data compression. To setup a call using SIP, mediaterminating device 104 sends an INVITE message to the access network108, which forwards the message to the media terminating device 120.Following, the access network 108 will notify media terminating device104 that the access network 108 is attempting to contact the mediaterminating device 120. The media terminating device 120 will return aringing notification to the access network 108 upon receiving the INVITEmessage, and the access network 108 will forward the ringing message tothe media terminating device 104. Once a user answers the mediaterminating device 120, for example, the media terminating device 120will send a 200 OK message to the access network 108, which forwards the200 OK message to media terminating device 104. The media terminatingdevice 104 will then send an ACK message to the media terminating device120 and an RTP media session is established.

Subsequently, suppose media terminating device 120 determines that thedata compression technique needs to be adjusted. The media terminatingdevice 120 then sends an INVITE message to the media terminating device104. This INVITE message is referred to as a “re-INVITE” message. There-INVITE message will contain information corresponding to the new datacompression technique. The media terminating device 104 will send a 200OK message and an ACK message to the media terminating device 120 inresponse to the re-INVITE message. Then, the media terminating devices104 and 120 would transfer data through an RTP media stream according tothe selected compression technique.

Alternatively, the call control server 112 may receive the reportsgenerated by the media terminating devices 120 and 104 and thendetermine that the data compression technique for data transfer betweenthe media terminating devices 120 and 104 should be adjusted. The callcontrol server 112 may then signal to the media terminating devices 120and 104 to inform them of the new compression format.

The call control server 112 or the network devices may select a datacompression technique to be used during a call based on many types ofinformation or using many different techniques. Below are a fewexamples. However, it should be understand that many other equivalenttechniques exist as well, and those described below are only exemplary.

In one embodiment, the call control server 112 or the media terminatingdevices 104 and 120 may use existing call log information (such as thatshown above in Table 3 or Table 4) to determine optimum data compressiontechniques for data transfer between two network devices. Similar toabove, the call control server 112 and the network devices may haveaccess to a call history database (such as the database 114) thatincludes information relating to prior calls between the twocommunicating network devices. Rather than accessing the database duringcall setup, the call control server 112 or the network devices couldaccess the database during the call so that call setup would not bedelayed, for example.

In addition, the call control server 112 or the network devices maymonitor call connection performance (or data transfer rates) and mayadjust the data compression to conform to the performance that theconnection is providing at any given moment. For example, callperformance parameters such as delay, jitter, and compression ratio canbe measured in real time for a call. If the data transfer has anunacceptable delay, or if the network provides various latency fordifferent data packets, then the data compression technique may need tobe adjusted. As one particular example, if data transfer rates areunacceptably slow during the call, then the data may be compressed at ahigher level, so that smaller sized data packets are being transferredto relieve stress on the network and open up additional bandwidth forfaster data transfer.

Smart Network Device Feedback

In another embodiment, smart network devices (e.g., bridges or routers)may inform the call control server 112 or the network devices that thedata compression technique should be adjusted. FIG. 9 is a block diagramillustrating one embodiment of a system 900 including smart networkdevice feedback. The system 900 is similar to the system 600 in FIG. 6,except that the media terminating devices 104 and 120 are coupled to thedata network 110 through a switch 122 and a gateway 124, and a thirdmedia terminating device 126 is connected to the data network. Theswitch 122 and the gateway 124 both help to ensure that data is sent toa desired destination. In addition, the switch 122 and the gateway 124may identify if the data was being transferred over a slow link withoutdata compression, for example, and then notify the call control server112 that the source/destination address pair was transferring data withno compression over a slow link. As another example, if data wascompressed and then transferred between two addresses or subnets thatare known to be interconnected with high speed links, then the callcontrol server 112 could be notified that the source/destination subnetpair was using compression over high speed links when compression maynot be necessary.

Thus, the switch 122 and the gateway 124 operate as smart networkdevices in a sense that the switch 122 and the gateway 124 can monitordata transfer between network devices and determine whether to adjust adata compression technique for the data transfer. For example, theswitch 122 would transfer data directly between the media terminatingdevices 104 and 120. The switch 122 would determine that both devices104 and 120 reside on itself, and thus if the switch 122 observescompressed data being transferred then the switch 122 could inform thedevices 104 and 120 that data compression is unnecessary because bothdevices 104 and 120 reside on the same switch.

Alternatively, if the media terminating device 120 was communicatingwith the media terminating device 126, then data would be transferredthrough the gateway 124 and the data network 110. As a result, the datamay need to be compressed since the data network 110 may not haveunlimited bandwidth available. Thus, the gateway 124 may monitor thedata transfer to determine if the data is sufficiently compressed. Ifthe gateway 124 determines that the compression technique should beadjusted, the gateway 124 would inform the media terminating devices 120and 104 to change their codecs as described in FIG. 8.

The smart devices could also send reporting messages to the call controlserver 112 to be stored and used to select data compression techniquesfor future calls. In this manner, the call control server 112 couldidentify during call setup that media terminating devices 120 and 104reside on the same switch, and that no data compression is necessary forthe data transfer between these devices.

Thus, during the call, network equipment or smart devices may determinethat data should or should not be compressed for data transfer throughthe smart devices. The smart network devices may also recognize whenindividual links become stressed or that bandwidth has become limited,and the network equipment could then inform the network devices or thecall control server 112 to force data compression.

It is intended that the foregoing detailed description be regarded asillustrative rather than limiting, and it is intended to be understoodthat the following claims including all equivalents define the scope ofthe invention.

1. A method for selecting a data compression technique for data transfer through a network between a first network device and a second network device comprising: receiving information of a configuration of the network between the first network device and the second network device, wherein the information includes intermediary links in a data transfer path between the first network device and the second network device; and selecting the data compression technique for data transfer through the network between the first network device and the second network device based on the information. 2-48. (canceled) 